The Programming Model
To best understand the programming model and which bits you need write it helps to understand the different elements involved when processing messages and which of them you can control.
Inbound Message Flow Stage
Inbound message flow is triggered by data being received by a transport (such as a record being written to a DB or data written to a socket). The Mule transport provider is responsible for receiving this data and wrapping into a Mule Message. The Inbound router is responsible for applying routing logic to the inbound Message, such as Idem potency, re-sequencing, batching, etc.
 | MuleMessage Contruction The MuleMessage is constructed by taking the body of the received data as the payload and any message headers and meta information (such as Filename in the File Transport). For example the Content-Type of a Http request can be read using - MuleMessage.getStringProperty("Content-Type", null) or a JMS header such as JMSPriority can be read using - MuleMessage.getIntProperty("JMSPriority") If the underlying transport supports attachments (such as SOAP and Mail) these will be added to the MuleMessage attachments. |
Endpoint
The Endpoint is used to receive messages from a transport. An endpoint is a configuration object that defines how data will be received and transformed by Mule. On the Endpoint you can configure the endpoint address, transport-specific configuration information, transactions and filters. For more information see Mule Endpoints.
Inbound Router
Inbound Routers control the inbound flow of events to a component and can re-sequence, aggregate or filter incoming messages. For example the IdempotentReceiver will reject any inbound messages that have already been received. The CorrelationResequencer will 'hold' a number of correlated events and hand them to the component in the correct order (based on the order they were dispatched).
| Element | Customisation | Coding Required |
| Endpoint (Inbound) | An endpoint is a configuration of a Mule transport. To introduce a new endpoint means to introduce a new transport. There is a guide to writing mule transports here. You can also customise the behaviour of an existing transport to change the way messages are received or dispatched. For more information about doing this see General Transport Configuration. | Writing your own transports is the most labour-intensive customisation in Mule. However, Most of the work is done for you with Abstract classes leaving template methods where the transport-specific code should be written. |
| Inbound Router | Mule provides a number of standard Inbound Routers that can be used without any customisation. The only reason customisation is necessary is when custom logic is required to do things like aggregate a set of events. | Only the routers such as the CorrelationAggregator need customisation in order to plug in logic to aggregate many events into one event. |
Component Flow Stage
Component flow starts when the MuleMessage is passed to the Model (Service container). Here the message will be passed to your Service object, but before that Interceptors and transformers can be invoked as part the inbound Message flow.
Interceptor (pre)
Interceptors are used to intercept message flow into your service component. They can be used trigger monitor/events or interrupt the flow of the message i.e. an authorisation interceptor could ensure that the current request has the correct credentials to invoke the service.
Inbound Transformer
Inbound transformers are used to transform the inbound message from the underlying transport format to something that the Service Component needs. Transformers can be chained together and should be used for data-level transforms i.e. from one data-type/format to another.
| Complex Transformations Advanced transformations where access to external data sources is required such as enrichment or lookup data it is recommended that a Service Component is introduced to perform this task rather than using a Transformer object is used for simpler data marshalling. |
Service Invocation
The service is the business logic. It can be a POJO, EJB, Remote Object or any other type of object. The Service component can be instantiated by the mule Model or it can be created by or stored in another container such as Spring, Hivemind, JNDI, Pico or Plexus.
Invoking the Service
Todo
Implementing the Callable interface
For more information see the Writing Components chapter.
Interceptor (post)
If an interceptor configured on the Service is an Envelope Interceptor (it extends org.mule.interceptors.EnvelopeInterceptor) The after() method will be called allowing developers to hook in behaviour once the component has finished processing.
| Element | Customisation | Coding Required |
| Interceptor (pre) | Can be used to introduce cross-cutting behaviour for components such as authorisation. | A single method interface to implement org.mule.umo.UMOInterceptor. |
| Inbound Transformer | Transformers are used to transform the message payload from one data format to another. Transformers can be chained together so that fine-grained transformers can be reused. Mule provides a number of transformers for XML and XSLT as well as transformers for standard java types . Transports are required to provide transformers for converting to and from underlying data formats. | There is an AbstractTransformer that all transformers should extend. This provides a single abstract method doTransform(...) that must be implemented. There is also an AbstractEventAwareTransformer that will also get passed the current UMOEventContext for the message flow. |
| Service Invocation | This is where the service object actually gets invoked. It can be a POJO, EJB, Remote object or objects instantiated by a container such as Spring or Hivemind. | This object has to be written by the developer and can be as simple or complex as the service requires. The service object itself need not have any reliance or knowledge about mule. Service Components should be stateless or manage any state in a shared data repository, unless the component is not running concurrently. |
| Interceptor (post) | Used to introduce any cross-cutting behaviour after the service component has executed. | Developers need to extend the EnvelopeInterceptor and implement any logic in the after() method. |
Outbound Flow Stage
The Outbound message flow starts one the result message (output from a Service Invocation) is passed on from the Service. If there is no result message or no Outbound Router configured this stage is skipped.
Outbound Router
The Outbound Router is responsible for controlling how and where the message goes next. Mule defines a number of standard Outbound Routers including all those listed in the excellent Enterprise Integration Pattern Book plus some other routing patterns that we have seen. Outbound Routers allow for Content-based, Itinerary (routing slip), Dynamic and Header-based routing or a combination of these. Mule has standard routers for MessageSplitting, Multicasting and content-based routers.
Outbound Transformer
TODO
Endpoint (outbound)
Note that there can be zero or more endpoints that the event gets dispatched on depending on the Outbound Router logic.
TODO
| Element | Customisation | Coding Required |
| Outbound Router | ||
| Outbound Transformer | ||
| Endpoint (Outbound) |
Messages and Events
TODO
The UMOEventContext
TODO
